REMARKS 

Claims 1-31 and 96 are currently pending in the application. 

35 U.S.C. S 103 Rejections: 

Claims 1, 6-10, 15-19, 28-31 and 96 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Stancil, U.S. Patent 7,149,927, in view of Luke, U.S. Patent 
6,505,267 and in further view of Steely, U.S. Patetnt 5,581,719. Applicant respectfully 
traverses this rejection. 

The cited references, taken singly or in combination, fail to teach or suggest 
all of the elements of the independent claims. Independent claim 1 recites, in pertinent 
part: 

"An SMBus host controller comprising 

a memory storing microcode comprising at least two programs each for 
handling a bus command protocol, each program comprising at least one 
instruction; ... 

an instruction fetch unit configured to read an instruction at an address in 
said memory , said address being specified by a program counter; 
a finite-state machine configured to receive and interpret the instructions 
read by said instruction fetch unit and manage the data transfer between 
the SMBus interface and a register set in compliance with said instructions 
read from said memory ; . . . and 

an address register array comprising a plurality of starting addresses of 
programs stored in said memory, said register comprising an offset for 
pointing at a specific register in said address register array (Emphasis 
added). 

Independent claims 10 and 19 recite similar combinations of features. 
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In the office action, the Examiner continues to argue that Standi teaches a finite- 
state machine, citing elements 112 and 116 of Fig. 2. However, the Examiner has not 
addressed the element of "a finite-state machine configured to ... interpret the 
instructions read by said instruction fetch unit." Standi is also silent with regard to 
elements 112 and/or 116 interpreting instructions. In fact, the only discussion of 
elements 112 and 1 16 in Standi occurs in col. 4, lines 14-32, which state the following: 



FIGS. 2-5 provide further detail regarding SMBus-to-JTAG emulator 110 
pertaining to how the emulator converts between SMBus and JTAG. A 
more detailed block diagram of emulator 110 is shown in FIG. 2. As 
shown therein, the emulator 110 preferably comprises an SMBUs state 
machine 112, an SMBus packet decoder/encoder 114 and a JTAG 
interface logic state machine 116. The SMBus state machine 112 
comprises logic that receives SMBus packets from the host test system 
102 and, with the help of the SMBus packet decoder/encoder 114. extracts 
the information from the packets necessary for the JTAG logic 122. The 
decoder/encoder 114 then creates JT AG-compliant communications that 
are sent to the JTAG logic 122 associated with the DUT 120 under the 
control of the JTAG interface logic state machine 116 . Similarly, JTAG 
communications from the JTAG logic 122 are received by state machine 
116 . decoded by decoder/encoder 114 and are converted to SMBus- 
compliant packets by decoder/encoder 114 and provided to the host test 
system 102 under the control of the SMBus state machine 1 12. (Emphasis 
added). 

Nothing in the above citation provides any teaching or suggestion that either of elements 
112 or 116 interpret instructions . Furthermore, Luke provides no teaching or suggestion 
that, taken singly or in combination with Standi, would result in any a finite-state 
machine configured to . . . interpret the instructions read by said instruction fetch unit." 
Thus Standi fails to teach or suggest that elements 112 and/or 116 interpret instructions, 
while Luke and Steely fail to provide any teaching or suggestion that would remedy this 
deficiency. Accordingly, Stancil in view of Luke and Steely fails to teach or suggest 
"a finite-state machine configured to ... interpret the instructions read by said 
instruction fetch unit." 



Furthermore, contrary to the Examiner's contention, Stancil in view of Luke and 
Steely fails to teach or suggest "an instruction fetch unit configured to read an instruction 
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at an address in said memory, said address being specified by a program counter." In the 
office action, the Examiner acknowledges that "Standi does not explicitly teach ... an 
instruction fetch unit configured to read instruction at an address from said memory." 
The Examiner then contends that Luke teaches this element, citing element 90 of Fig. 6 
and col. 7, lines 17-19 of Luke. Element 90 of Luke is taught as an op code latch: 

An op code latch 90 stores the operational code for the present sequencer 
command addressed by the program counter 84. (Luke, col. 7, lines 17- 
19, emphasis added). 

In the above citation, Luke provides no teaching or suggestion of op code latch 90 
reading instructions from a memory. Moreover, Luke provides no additional details of 
op code latch 90 elsewhere, as the discussion of this element is limited to the portion 
cited above. The Examiner has further failed to explain how op code latch 90 would read 
an instruction from an address in memory, nor had the Examiner explained why op code 
latch would perform this function if combined with Standi. 

The Examiner then cites Luke at col. 9, lines 14-20 as teaching the portion of the 
element wherein the alleged instruction fetch unit is "configured to read instruction at an 
address from said memory": 

SUBR Causes a jump to a subroutine in external memory device 32. The 
sequencer 46 jumps to the address specified in the external memory 
device 32 and executes whatever codes that were previously 
programmed into the external memory device 32. The sequencer 46 
continues sequentially executing instructions in the external memory 
device 32 until coming across a RETN command. 

Nothing in the above citation teaches or suggests that the subroutine, codes, or 
instructions discussed in the above citation are read by op code latch 90. As previously 
noted, the discussion of op code latch 90 in Luke's description is limited to col. 7, lines 
17-19. Thus, Luke is silent with respect to op code latch 90 performing any function 
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other than storing "operational code for the present sequencer command." Steely provides 
no teaching or suggestion that would remedy the deficiency of Standi in view of Luke. 
Thus, since Luke and Steely fail to remedy the acknowledged deficiency in Stancil, 
the prior art references, taken singly or in combination, fail to teach or suggest "an 
instruction fetch unit configured to read an instruction at an address in said 
memory, said address being specified by a program counter." 

Applicant further submits that, even if one were to accept the Examiner's 
contention regarding op code latch 90 being equivalent to Applicant's recited instruction 
fetch unit (a contention with which Applicant does not agree), there would still be no 
motivation to make the proposed combination with Stancil. As noted above, Stancil does 
not teach or suggest "a finite-state machine configured to . . . interpret the instructions 
read by said instruction fetch unit," while Luke fails to remedy this deficiency. More 
particularly, since Stancil fails to provide any teaching or suggestion that elements 112 
and/or 116 interpret instructions, one of ordinary skill in the art would not be motivated 
to provide an instruction fetch unit for these elements, as they would be incapable of 
interpreting fetched instructions. Accordingly, in addition to the Stancil in view of 
Luke and Steely failing to tech all of the elements of the claims, there is no 
motivation to make the combination proposed by the Examiner. 

For at least the reasons given above, Applicant submits that Stancil in view of 
Luke and in further view of Steely fails to teach or suggest all of the elements of the 
independent claims, as well as their associated dependent claims. Accordingly, removal 
of the 35 U.S.C. § 103(a) rejection is respectfully requested. 
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CONCLUSION: 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5500- 
92201 /EAR 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: May 5. 2009 
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